Skip to content

snagrecover: am6x: Support J721e platforms#84

Open
RomainNaour wants to merge 1 commit intobootlin:mainfrom
RomainNaour:snagrecover-add-j721e-support
Open

snagrecover: am6x: Support J721e platforms#84
RomainNaour wants to merge 1 commit intobootlin:mainfrom
RomainNaour:snagrecover-add-j721e-support

Conversation

@RomainNaour
Copy link
Copy Markdown

Support the J721e/DRA829/TDA4VM SoC family.

Its recovery flow is almost identical to the typical AM6x flow, the only major difference being an additional "sysfw.bin" binary firmware needed for "Split binary with a split firmware" boot flow [1] (like the AM654). Update send_tiboot3() accordingly to download "sysfw.bin" after "tiboot3.bin".

Add a new snagrecover template with all four binaries: tiboot3.bin, sysfw.itb, tispl.bin and u-boot.img.

Use USB Vendor ID and Product ID from the TDA4VM TRM in Table 4-66 USB Boot Parameter Table [2]:

Vendor ID = 0x451
Product ID = 0x6163

But latter in 4.6.8.1.1 DFU Device Mode chapter the Product ID is the same as the am65 SoC (0x6162). This is likely a typo since Product ID 0x6163 is the one used by u-boot for the J721e EVM board [3].

Add Product ID 0x6163 to the TI rules list.

Tested on SK-TDA4VM [4] board using its usb-c port by setting SW1 switch in USB boot mode, see the user manual [5].

[1] https://docs.u-boot.org/en/latest/board/ti/k3.html#boot-flow-variations
[2] https://www.ti.com/lit/zip/spruil1
[3] https://source.denx.de/u-boot/u-boot/-/blob/v2026.01/configs/j721e_evm_r5_defconfig#L177
[4] https://www.ti.com/tool/SK-TDA4VM
[5] https://www.ti.com/lit/pdf/SPRUJ21

Support the J721e/DRA829/TDA4VM SoC family.

Its recovery flow is almost identical to the typical AM6x flow, the
only major difference being an additional "sysfw.bin" binary firmware
needed for "Split binary with a split firmware" boot flow [1]
(like the AM654). Update send_tiboot3() accordingly to download
"sysfw.bin" after "tiboot3.bin".

Add a new snagrecover template with all four binaries: tiboot3.bin,
sysfw.itb, tispl.bin and u-boot.img.

Use USB Vendor ID and Product ID from the TDA4VM TRM in Table 4-66
USB Boot Parameter Table [2]:

  Vendor ID = 0x451
  Product ID = 0x6163

But latter in 4.6.8.1.1 DFU Device Mode chapter the Product ID is
the same as the am65 SoC (0x6162). This is likely a typo since
Product ID 0x6163 is the one used by u-boot for the J721e EVM board
[3].

Add Product ID 0x6163 to the TI rules list.

Tested on SK-TDA4VM [4] board using its usb-c port by setting SW1
switch in USB boot mode, see the user manual [5].

[1] https://docs.u-boot.org/en/latest/board/ti/k3.html#boot-flow-variations
[2] https://www.ti.com/lit/zip/spruil1
[3] https://source.denx.de/u-boot/u-boot/-/blob/v2026.01/configs/j721e_evm_r5_defconfig#L177
[4] https://www.ti.com/tool/SK-TDA4VM
[5] https://www.ti.com/lit/pdf/SPRUJ21

Signed-off-by: Romain Naour <romain.naour@smile.fr>
@RomainNaour
Copy link
Copy Markdown
Author

I checked other (newer) TI SoC about their "Product ID" value... and it's a mess.

Every time we have to double check the "Product ID" really used in u-boot. We can also check the CTRLMMR_USB_DEVICE_ID register reset value.

Here is my draft for other TI SoC (I reordered some lines, removed the "am654x" since it use the wrong device ID)

"am6x": {
	# K3 AM62x
	"am623": "0451:6165",
	"am625": "0451:6165",
	# K3 AM62a
	"am62a7": "0451:6165",
	# K3 AM62d
	"am62d2": "0451:6165",
	# K3 AM62p
	"am62p": "0451:6165",
	# K3 AM64xx
	"am6411": "0451:6165",
	"am6412": "0451:6165",
	"am6421": "0451:6165",
	"am6422": "0451:6165",
	"am6441": "0451:6165",
	"am6442": "0451:6165",
	# K3 AM654x
	"am6548": "0451:6162",
	"am6546": "0451:6162",
	# K3 J7200/DRA821
	"j7200": "0451:6164",
	# K3 J721e/DRA829/TDA4VM/AM68p
	"j721e": "0451:6163",
	# K3 J722S/TDA4VEN/TDA4AEN/AM67
	"am67": "0451:6165",
	# K3 J721S2/TDA4VE/TDA4AL/TDA4VL/AM68
	"am68": "0451:6168",
	# K3 J784S4/AM69x/TDA4VH/TDA4AH/TDA4VP/TDA4AP
	"am69": "0451:6168",
},

About SoC family naming "am6x", It should be "K3" to include other TI SoC using "K3 Multicore SoC architecture platform". Indeed not all TI SoC are named "AM6x": DRA829, DRA821, TDA4VM...

For the J721e, the "AM68p" variant doesn't really exist (it appear only in the TRM). It should not be confused with the "real" AM68 that is a "J721S2" SoC.

Do you really want a exhaustive list of SoC or can we use their "generic" names ? or have all variant name?

	# K3 J722S/TDA4VEN/TDA4AEN/AM67
	"j722s": "0451:6165",
	"tda4ven": "0451:6165",
	"tda4aen": "0451:6165",
	"am67": "0451:6165",

Copy link
Copy Markdown
Collaborator

@rgantois rgantois left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, thanks a lot for the contribution! Looks good to me, aside from a small nitpick which I've mentionned


if recovery_config["soc_model"].startswith("am654"):
# Download sysfw.itb if your device (AM654, j721e) uses the split binary boot flow
# https://docs.u-boot.org/en/latest/board/ti/k3.html#boot-flow-variations
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should go in docs/snagrecover.md in the fw_binaries TI section. sysfw.itb is already mentionned for AM654 there, maybe just modify that sentence to mention the new SoC as well. You can add the documentation link there as well.

@rgantois
Copy link
Copy Markdown
Collaborator

rgantois commented Apr 9, 2026

About SoC family naming "am6x", It should be "K3" to include other TI SoC using "K3 Multicore SoC architecture platform". Indeed not all TI SoC are named "AM6x": DRA829, DRA821, TDA4VM...

Sure, I'd be open to that change.

For the J721e, the "AM68p" variant doesn't really exist (it appear only in the TRM). It should not be confused with the "real" AM68 that is a "J721S2" SoC.

Do you really want a exhaustive list of SoC or can we use their "generic" names ? or have all variant name?

The granularity is different for each SoC family. For TI, I've decided to be quite specific with the SoC model since the boot procedure is quite complex, so I expect some potential for breaking variations from one model to another.

So ideally for TI, we'd have one model name for each separate commercialized SoC. Now for rebranded SoCs where the chip is exactly the same but with a different name, I don't expect an exhaustive list. SoC aliases can always be added later if needed, like we did for i.MX8MP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants